home *** CD-ROM | disk | FTP | other *** search
/ SuperView Productivity Suite 2 / SuperView Productivity Suite 2.iso / BONUS / PROGS / StackAid.lha / StackAid / StackAid.readme < prev   
Text File  |  1998-08-06  |  5KB  |  179 lines
  1. Short: Avoid STACK related gurus (Ramlib/IPrefs) V1.5
  2. Type: util/sys
  3. Uploader: Andreas_Kleinert@t-online.de
  4. Author: Andreas R. Kleinert, Jim Cooper, Jorma Oksanen
  5. Requires: OS 2.04 (V37) or higher
  6. Replaces: RamLibPatch.lha, IPrefsPatch.lha
  7.  
  8.  
  9.  First:
  10.  
  11.  If some program crashes, it's bad.
  12.  Even if these patches helps, it's no excuse.
  13.  
  14.  
  15.  Also:
  16.  
  17.   - don't use these patches if you don't need them,
  18.     i.e. if your system does not crash at all...
  19.   - "one patch more", may be "one patch too much"
  20.   - first try to remove some of the other patches
  21.     that you may be running
  22.   - if it works for you, and helps to fix some
  23.     bugs, only use it temporarily; when you upgrade your
  24.     system's software configuration, i.e. that parts that
  25.     are likely to cause such problems, next time,
  26.     then try again without these patches
  27.  
  28.  Additionally:
  29.  
  30.   - what "IPrefsPatch" and "RamLibPatch" do, is completely
  31.     illegal in terms of system-conformeous programming.
  32.     Those patches do work _accidentally_ with those two
  33.     processes - if you try the same kind of patch with
  34.     other programs, it most likely WON'T work as it should
  35.     (so, DON'T try that, as e.g. the "PatchStack" or
  36.     "ksc_GowStack" tools do suggest - this was NOT my
  37.     intention by releasing the sources/idea)
  38.  
  39.  
  40.  General
  41.  =======
  42.  
  43.    - try increasing the stack inside the Boot shell,
  44.      where s:startup-sequence is executed. For
  45.      example by adding the following line to it:
  46.  
  47.         C:SetPatch QUIET        ; and then:
  48.         Stack >NIL: <NIL: 8192
  49.  
  50.    - on some systems IPrefs causes problems, while
  51.      on other systems FastIPrefs causes problems
  52.      (due to higher stack usage). Try switching
  53.      between both, while only using the LATEST
  54.      version of FastIPrefs: take a look at the
  55.      author's homepage under:
  56.  
  57.          http://www.neuss.netsurf.de/~chbenitz/hws.html
  58.  
  59.  
  60.  
  61.  RamLibPatch
  62.  ===========
  63.  The "ramlib" task, which Exec uses to manage
  64.  library loading and initialization, under
  65.  OS 33-40 (Kickstart 1.2 upto AmigaOS 3.1)
  66.  only has a stack sized 2050 (2048) bytes.
  67.  
  68.  This may easily lead to crashes, when
  69.  
  70.    a) libraries load many other libraries,
  71.       that load many other libraries, that...
  72.  
  73.    b) some of these libraries do need a
  74.       lot of stack space during initialization
  75.  
  76.  Unfortunately, there is no legal way to
  77.  increase/swap stacks of foreign tasks
  78.  under AmigaOS.
  79.  
  80.  However, this small patch program does
  81.  try it nevertheless, and it seems to
  82.  work flawlessly.
  83.  
  84.  "RamLibPatch" increases the stacksize of
  85.  the "ramlib" task to 8 K (if not already
  86.  done) and furthermore should keep all
  87.  that nasty "ramlib guru #3" crashes away
  88.  from your system.
  89.  
  90.  Usage:  - call it from the Shell first,
  91.            and check, whether it works
  92.            for you
  93.          - make some extensive tests,
  94.            e.g. with datatypes and
  95.            other libraries
  96.          - if it works ok, put it to
  97.            your s:startup-sequence
  98.            right after SetPatch:
  99.  
  100.              Run >NIL: <NIL: RamLibPatch
  101.  
  102.  Drawbacks:
  103.  
  104.  The old stack never will be given back
  105.  to the system, as also won't be the new
  106.  one - until the next reboot.
  107.  
  108.  
  109.  
  110.  IPrefsPatch
  111.  ===========
  112.  The "IPrefs" task, which Workbench uses for
  113.  various preferences stuff, including Workbench
  114.  background patterns, under OS 37-40 (AmigaOS 2.04
  115.  upto 3.1) only has a stack sized 3500 bytes.
  116.  
  117.  This may easily lead to crashes, when datatypes
  118.  are used for pattern loading, that have internal
  119.  requirements that are higher - usual symptoms
  120.  are, that MultiView works flawlessly on an
  121.  image, while WBPattern crashes immediately.
  122.  
  123.  Unfortunately, there is no legal way to
  124.  increase/swap stacks of foreign tasks
  125.  under AmigaOS.
  126.  
  127.  Two possible solutions came up:
  128.  
  129.    1. Patching the IPrefs executable
  130.       (since other than Ramlib it's not in ROM)
  131.       directly to a different stacksize
  132.       (problem: may not work for every revision)
  133.  
  134.       Usage:   - run it with "rx" from Shell
  135.  
  136.    2. Do it the same way as with Ramlib, and
  137.       try to increase the stack nevertheless
  138.       (which seems to work flawlessly, but may
  139.       sometimes be "too late" in the s:startup-
  140.       sequence).
  141.  
  142.       "IPrefsPatch" increases the stacksize of
  143.       the "IPrefs" task to 8 K (if not already
  144.       done) and furthermore should keep all
  145.       that nasty "stack overflow" crashes away
  146.       from your system.
  147.  
  148.       Usage:  - call it from the Shell first,
  149.                 and check, whether it works
  150.                 for you
  151.               - make some extensive tests,
  152.                 e.g. with some datatypes
  153.                 fromout IPrefs, try to change
  154.                 the WB screenmode once ("use")
  155.               - if it works ok, put it to
  156.                 your s:startup-sequence
  157.                 right after IPrefs:
  158.  
  159.                   Run >NIL: <NIL: IPrefsPatch
  160.  
  161.       Drawbacks:
  162.  
  163.       The old stack never will be given back
  164.       to the system, as also won't be the new
  165.       one - until the next reboot.
  166.  
  167.  
  168.  Well, last not least:
  169.  
  170.  I'm not responsible for anything, there's no guarantee for anything,
  171.  and all mentioned trademarks are subject to their owners :-)
  172.  
  173.  
  174.  Changes since V1.3: - adjusting Process structure as well, now
  175.  Changes since V1.4: - added ARexx script by Jorma Oksanen
  176.  
  177. --
  178. ARK, 06/Aug/98
  179.